Software-defined networking (SDN) has recently emerged as a new network paradigm which enables network administrators to manage network services by abstracting lower-level functionality. In essence, SDN decouples the layer of the routing architecture that determines the paths along which network traffic should be sent (Control Plane) from the layer that forwards network traffic along those paths to its desired destinations (Forwarding Plane—sometimes also referred to as the Data Plane, Transport Plane or Flow Plane). In doing so, distributed Control Plane logic can be physically removed from multiple routing and switching devices and implemented, for example, in software running on a centralized server.
The Control Plane maintains the “network map” (also referred to as the network topology or system topology), which defines network nodes (including physical network devices) and their interconnections. In addition, the Control Plane maintains the rules for “routing” network traffic among these network nodes.
This system topology encompasses not only physical connections among network nodes, but also manually configured static routes, status information from hardware devices and software-defined interfaces, as well as information derived from dynamic routing protocols. The Control Plane ultimately determines the “best” route for particular network traffic, optimizing for various desired goals, such as “quality of service” (QoS) or minimal network congestion.
The Forwarding Plane implements the routes established by the Control Plane—e.g., determining how to forward packets arriving at a router's inbound interface to its appropriate outbound interfaces. The Forwarding Plane implements lower-level functionality, such as extracting and analyzing information from packet headers and other fields, traversing and caching portions of large routing tables, and employing various search and memory management algorithms to efficiently route packets to their intended destinations.
In traditional network devices, the Control Plane and Forwarding Plane both exist within the same physical device (the Control Plane being distributed across many or all of the devices that make up the network). SDN physically separates the Control Plane from the Forwarding Plane, effectively requiring a more robust protocol for communication between the two Planes.
“OpenFlow” (from the Open Networking Foundation, or ONF) is one popular standard that has emerged to implement a communications interface between physically disparate Control Plane and Forwarding Plane layers of an SDN network architecture. While other communications protocols could be employed, OpenFlow has achieved such widespread acceptance that it is often used synonymously with SDN. The term, “SDN Flow” (or simply “traffic path”) is typically used to represent a path or route that particular network traffic can traverse between its source and destination network devices.
By separating the Control Plane (implemented, for example, in software on a server, often referred to as an “SDN Controller”) from the Forwarding Plane software and firmware embedded in physical switches and routers, an SDN network architecture facilitates virtualization not only of the lower-level hardware Infrastructure Layer, but also of the higher-level Application Layer. For example, an SDN Controller can communicate, via well-defined Application Programming Interfaces (APIs), with applications running on a network in order to optimize particular SDN Flows relevant to a particular application (“Application Optimization”) or to the network as a whole (“System Optimization”). Moreover, “Predictive Optimization” of an application or entire network can be implemented over time, for example, based on historical performance over various time periods or during a particular time of day. Various other advantages of SDN network architectures can be found, for example, at http://www.opennetsummit.org/why-sdn.html.
As alluded to above, network nodes consist not only of individual hardware devices (e.g., routers, switches, servers, optical transponders, multiplexers, etc.) that communicate with one another at the Infrastructure Layer, but also of more abstract “Application Components” (e.g., web servers, storage arrays and databases, Corporate LANs, E-Commerce storefronts, etc.) that are utilized by software applications and communicate with one another at the Application Layer. An SDN Controller can generate optimized SDN Flows among Application Components at the Application Layer, which can then be translated into lower-level SDN Flows at the Infrastructure Layer (and implemented, for example, by the Forwarding Plane of various network devices interconnecting those Application Components).
Whether optimizing performance among low-level hardware devices at the Infrastructure Layer, or Application Components at the Application Layer, or even the overall system, SDN Controllers rely on data extracted from the network, often in real-time while individual applications are running.
For example, “Network Metrics” (number of hops between nodes, bandwidth, latency, packet loss, etc.) typically reflect the performance of low-level hardware devices, such as routers and switches, at the Infrastructure Layer.
“Application Metadata,” on the other hand, provide more abstract performance data at the higher-level Application Layer. Application Metadata includes, for example, various performance metrics such as overall throughput, transaction rate, elapsed transaction times, thread counts, number of concurrent users, number of running instances, uptime or downtime metrics, database size or other storage metrics, memory/disk/CPU utilization rates, etc. It also includes errors, warnings and related events maintained in application log file entries, as well as monitoring metrics of message queues (e.g., messages per second, failures, etc.). Moreover, Application Metadata includes data generated by dedicated monitoring systems, including security monitors, firewalls (including deep packet inspectors), WAN accelerators, load balancers, etc.
At a more conceptual level, purchasing a popular DVD on “Black Friday” at Amazon, for example, may take longer than on other days due to an unusually high number of concurrent users. Data logs generated by Amazon's E-Commerce storefront software may reflect the congested nature of such “busy day” transactions.
By employing a “System Environment Monitor” to extract Network Metrics and Application Metadata in real time, an SDN Controller can detect such unusual conditions and other anomalies at the system level or within a particular application, and employ “network analytics” to address them specifically (e.g., by increasing bandwidth to relevant servers), or more generally by optimizing traffic flow among Application Components or the system as a whole to achieve a particular desired goal, such as minimizing network congestion, or providing a particular QoS (e.g., a maximum latency for a particular type of transaction), among other objectives. As a result of such optimizations, an SDN Controller typically generates a revised set of SDN Flows—i.e., a remapping of network traffic routes among network nodes, including Application Components (typically “endpoints” of an SDN Flow) and lower-level hardware devices such as routers and switches (typically intermediate nodes between the Application Components over which network traffic is routed).
Various companies have recognized the value of leveraging network analytics to optimize their SDN Controller solutions—in particular by modifying SDN Flows. See, for example, recent integrated solutions from Brocade and Boundary:
Brocade/IBM                http://community.brocade.com/community/discuss/sdn/blog/2013/01/29/network-analytics-and-openflowsdn        
Boundary/Splunk                http://boundary.com/blog/2013/04/26/boundary-adds-application-context-data-to-splunk-enterprise/        
Boundary/Plexxi                http://boundary.com/product/boundary-product-integrations/boundary-software-defined-networking-sdn/        
Others have characterized their approaches to this problem using the term “SON” for self-organizing networks or self-optimizing networks, or “AON” for applications-optimized networks (see, e.g., http://www.nojitter.com/nost/240153039/hp-and-microsoft-demo-openflowlync-applicationsoptimized-network).
These “solutions,” however, fail to address certain significant realities of existing SDN networks. One such reality is the fact that implementing revised SDN Flows often disrupts existing SDN Flows (to be modified), as well as other real-time network traffic. Applications running on the network may, as a result of these attempted optimizations, experience downtime or errors that, in some cases, can be quite costly.
Another reality is the existence of “mixed” networks that encompass multiple different “Data Transfer Technologies” or DTTs. For example, many existing SDN networks include not only IP-based packet-switched devices (e.g., IP routers), but also optical circuit-switched devices (e.g., optical multiplexers and cross-connect switches). Other DTTs include wireless network devices, such as WiFi routers, cellular 3G, 4G and LTE routing devices, as well as various other types of routers, switches and other network devices. An SDN Controller with access to the entire system topology and application-to-application traffic paths (including the different characteristics of these various hardware components across multiple DTTs in a mixed network) is in a unique position to leverage this knowledge to better optimize SDN Flows—e.g., by generating one or more SDN Flows that traverse hardware components across multiple DTTs.
What is therefore needed is a system that can extract Network Metrics and Application Metadata in real time from a mixed technology (multi-DTT) network, and, in response, generate and implement modified SDN Flows in real time throughout the network in a non-disruptive manner.